📌 Summary

• 주간/월간 랭킹 집계 배치 구현

  • product_metrics, product_sku_metrics를 읽어 주간/월간 단위 점수 집계
  • DB 테이블(product_metrics_weekly, product_metrics_monthly)에 upsert 방식으로 저장
  • Spring Batch chunk(1000) 단위로 처리

• Redis 연동

• 배치 집계 완료 후 Redis ZSET에 반영

• BoundZSetOperations.add(Set) 방식으로 단순화

• 랭킹 조회 API 개선

  • 기존 GET /api/v1/rankings?date=yyyyMMdd&size=20 → period 파라미터 추가 (daily | weekly | monthly)

• JPA 대신 JdbcBatchItemWriter + SQL upsert 방식으로 변경 (대규모 집계 성능 고려)

• jdbc 방식선택에 따른 인덱스 추가

  • CREATE INDEX idx_pm_date_pid ON product_metrics(date, product_id);
  • CREATE INDEX idx_psm_date_pid ON product_sku_metrics(date, product_id);

💬 Review Points

- 집계된 ZSet 값을 집계하여 DB에 저장하는 방식에 대한 의견

• 현재 일간 점수는 Redis ZSET에 저장되고 있습니다. 때문에 일배치를 수행하며 Redis에서 일간 데이터를 합산하는 방법도 고려했으나
• 점수의 근거 데이터는 DB의 원천 테이블이므로, 이쪽을 기준으로 집계하는 것이 정합성 관리에 유리하다고 판단했고
• 일간/주간/월간 가중치가 동일하다는 보장이 없어, 정책 변경 시 원천 데이터 기반 집계가 재집계에 유리합다고 판단하여 원천테이블에서 합산을 진행하였습니다.
• 또한 성능 측면에서도 일별 ZSET을 반복적으로 합산하는 것보다 기간 쿼리 한 번이 더 빠르고
• 운영 복구 관점에서도 누락 데이터가 있을 경우 기간 조건만 바꿔 재실행이 가능해 관리가 간단합다고 생각하여
• 이에 따라 JdbcCursorItemReader로 기간 데이터를 한 번에 읽고, Processor에서 가중치와 캐리오버를 적용하는 구조로 설계했습니다.
• 현업에서는 Redis 기반 합산 방식을 선호하시실까요,,? 이유나 장점이 더 있다면 의견 부탁드립니다.

- JPA 대신 JdbcBatchItemWriter + SQL upsert 방식에 대한 의견

• Writer는 JPA saveAll() 대신 JdbcBatchItemWriter와 MySQL upsert(ON DUPLICATE KEY UPDATE)를 사용했습니다.
• 대용량 배치에서는 영속성 컨텍스트 관리 비용을 피한 JDBC 배치가 더 단순하고 일관되게 빠르다고 판단했고
• 또한 upsert로 재실행 시 멱등성을 쉽게 확보할 수 있어 운영 리스크를 낮출 수 있다고 보았습니다.
• 이러한 설계 방향에 대해서 어떻게 생각하시는지 궁금합니다.

✅ Checklist

🧱 Spring Batch

• Spring Batch Job 을 작성하고, 파라미터 기반으로 동작시킬 수 있다.
• Chunk Oriented Processing (Reader/Processor/Writer or Tasklet) 기반의 배치 처리를 구현했다.
• 집계 결과를 저장할 Materialized View 의 구조를 설계하고 올바르게 적재했다.

🧩 Ranking API

• API 가 일간, 주간, 월간 랭킹을 제공하며 조회해야 하는 형태에 따라 적절한 데이터를 기반으로 랭킹을 제공한다.

🚨Unfinished List

• 테스트코드